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Abstract 

We describe a type system for a platform called the General Intensional Programming System 
(GIPSY), designed to support intensional programming languages built upon intensional logic and 
their imperative counter-parts for the intensional execution model. In GIPSY, the type system glues 
the static and dynamic typing between intensional and imperative languages in its compiler and run- 
time environments to support the intensional evaluation of expressions written in various dialects of 
the intensional programming language Lucid. The intensionality makes expressions to explicitly take 
into the account a multidimensional context of evaluation with the context being a first-class value 
that serves a number of applications that need the notion of context to proceed. We describe and 
discuss the properties of such a type system and the related type theory as well as particularities of 
the semantics, design and implementation of the GIPSY type system. 

Keywords: Intensional Programming, Imperative Programming, Type System, Type Theory, Gen- 
eral Intensional Programming System (GIPSY), Context 

1 Introduction 

The GIPSY is an ongoing effort for the development of a flexible and adaptable multi-lingual program- 
ming language development framework aimed at the investigation on the Lucid family of intensional 
programming languages [jJl |2l |22l [U [121 IHl lEl [IB l- Using this platform, programs written in many 
flavors of Lucid can be compiled and executed. The framework approach adopted is aimed at provid- 
ing the possibility of easily developing compiler components for other languages of intensional nature, 
and to execute them on a language-independent run-time system. Lucid being a functional "data-flow" 
language, its programs can be executed in a distributed processing environment. However, the standard 
Lucid algebra (i.e. types and operators) is extremely fine-grained and can hardly benefit from parallel 
evaluation of their operands. Adding granularity to the data elements manipulated by Lucid inevitably 
comes through the addition of coarser-grained data types and their corresponding operators. Lucid se- 
mantics being defined as typeless, a solution to this problem consists in adding a hybrid counterpart to 
Lucid to allow an external language to define an algebra of coarser-grained types and operators. In turn, 
this solution raises the need for an elaborated type system to bridge the implicit types of Lucid semantics 
with the explicit types and operators (i.e. functions) defined in the hybrid counterpart language. This 
paper presents such a type system that is used in the GIPSY at compile time for static type checking, as 
well as at run-time for dynamic type checking. 

After our problem statement and short presentation of our proposed solution, this section presents 
a brief introduction to the GIPSY project III |6l [El EB [JOl |25l [111, and the beginnings of the GIPSY 
Type System [10] in the GIPSY to support hybrid and object-oriented intensional programming Il9ll24t. 
and Lucx's context type extension known as context calculus ll20l [151 [T9il for contexts to act as first- 
class values. Then, we present the complete GIPSY type system as used by the compiler (General 
Intensional Programming Compiler - GIPC) and the run-time system (General Eduction Engine - GEE) 
when producing and executing a binary GIPSY program (called General Eduction Engine Resources - 
GEER) respectively. 
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1.1 Problem Statement and Proposed Solution 

Problem Statement Data types are implicit in Lucid (as well as in its dialects or many functional lan- 
guages). As such, the type declarations never appear in the Lucid programs at the syntactical level. The 
data type of a value is inferred from the result of evaluation of an expression. In most imperative lan- 
guages, like Java, C-i-i- and the like, the types are explicit and the programmers must declare the types of 
the variables, function parameters and return values before they are used in evaluation. In the GIPSY, we 
want to allow any Lucid dialect to be able to uniformly invoke functions/methods written in imperative 
languages and the other way around and perform semantic analysis in the form of type assignment and 
checking statically at compile time or dynamically at run time, perform any type conversion if needed, 
and evaluate such hybrid expressions. At the same time, we need to allow a programmer to specify, or 
declare, the types of variables, parameters, and return values for both intensional and imperative func- 
tions as a binding contract between inter-language invocations despite the fact that Lucid is not explicitly 
typed. Thus, we need a general type system, well designed and implemented to support such scenarios. 

Proposed Solution The uniqueness of the type system presented here is that it is above a specific pro- 
gramming language model of either the Lucid family of languages or imperative languages. It is designed 
to bridge programming language paradigms, the two most general of them would be the intensional and 
imperative paradigms. GIPSY has a framework designed to support a common run-time environment 
and co-existence of the intensional and imperative languages. Thus, the type system is that of a generic 
GIPSY program that can include code segments written in a theoretically arbitrary number of intensional 
and imperative dialects supported by the system vs. being a type system for a specific language. What 
follows is the details of the proposed solution and the specification of the type system. 

1.2 Introduction to the GIPSY Type System 

The introduction of JLucid, Objective Lucid, and the General Imperative Compiler Framework (GICF) ifTOl 
milllll prompted the development of the GIPSY Type System as implicitly understood by the Lucid lan- 
guage and its incarnation within the GIPSY to handle types in a more general manner as a glue between 
the imperative and intensional languages within the system. Further evolution of different Lucid vari- 
ants such as Lucx introducing contexts as first-class values and JOOIP (Java Object-Oriented Intensional 
Programming) highlighted the need of the further development of the type system to accommodate the 
more general properties of the intensional and hybrid languages. 

1.2.1 Matching Lucid and Java Data Types 

Here we present a case of interaction between Lucid and Java. Allowing Lucid to call Java methods 
brings a set of issues related to the data types, especially when it comes to type checks between Lucid 
and Java parts of a hybrid program. This is pertinent when Lucid variables or expressions are used as 
parameters to Java methods and when a Java method returns a result to be assigned to a Lucid variable 
or used in an intensional expression. The sets of types in both cases are not exactly the same. The basic 
set of Lucid data types as defined by Grogono fS] is int, bool, double, string, and dimension. 
Lucid's int is of the same size as Java's long. GIPSY and Java double, boolean, and String are 
equivalent. Lucid string and Java String are simply mapped internally through StringBuf f er; thus, 
one can think of the Lucid string as a reference when evaluated in the intensional program. Based on 
this fact, the lengths of a Lucid string and Java String are the same. Java String is also an object 
in Java; however, at this point, a Lucid program has no direct access to any String's properties (though 
internally we do and we may expose it later to the programmers). We also distinguish the float data 
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Table 1 : Matching data types between Lucid and Java. 
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type for single-precision floating point operations. The dimension index type is said to be an integer 
or string (as far as its dimension tag values are concerned), but might be of other types eventually, as 
discussed in [20|. Therefore, we perform data type matching as presented in Table [T] Additionally, we 
allow void Java return type which will always be matched to a Boolean expression true in Lucid as an 
expression has to always evaluate to something. As for now our types mapping and restrictions are as 
per Table[T] This is the mapping table for the Java-to-IPL-to-Java type adapter. Such a table would exist 
for mapping between any imperative-to-intensional language and back, e.g. the C-i-i-to-IPL-to-C-i-i- type 
adapter. 

2 Simple Theory of GIPSY Types 

Our simple theory of the GIPSY types (STGT) is based on the "Simple theory of types" (STT) by 
Mendelson Q. The theoretical and practical considerations are described in the sections that follows. 
The STT partitions the qualification domain into an ascending hierarchy of types with every individual 
value assigned a type. The type assignment is dynamic for the intensional dialects as the resulting 
type of a value in an intensional expression may not be known at compile time. The assignment of 
the types of constant literals is done at compile-time, however. In the hybrid system, which is mostly 
statically typed at the code-segment boundaries, the type assignment also occurs at compile-time. On 
the boundary between the intensional programming languages (IPLs) and imperative languages, prior to 
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an imperative procedure being invoked, the type assignment to the procedure's parameters from IPL's 
expression is computed dynamically and matched against a type mapping table similar to that of Table[T] 
Subsequently, the when the procedure call returns back to the IPL, the type of the imperative expression 
is matched back through the table and assigned to the intensional expression that expects it. The same 
table is used when the call is made by the procedure to the IPL and back, but in the reverse order. 

Further in STT, all quantified variables range over only one type making the first-order logic ap- 
plicable as the underlying logic for the theory. This also means the all elements in the domain and all 
co-domains are of the same type. The STT states there is an atomic type that has no member elements 
in it, and the members of the second-high from the basic atomic type. Each type has a next higher type 
similarly to succ in Peano arithmetic and the next operator in Lucid. This is also consistent to describe 
the composite types, such as arrays and objects as they can be recursively decomposed (or "flattened", 
see [10]) into the primitive types to which the STT applies. 

Symbolically, the STT uses primed and unprimed variables and the infix set notation of G. The 
formulas ^{x) rely on the fact that the unprimed variables are all of the same type. This is similar to the 
notion of a Lucid stream with the point-wise elements of the stream having the same type. The primed 
variables (x') in STT range over the next higher type. There two atomic formulas in STT of the form of 
identity, x = y, and set membership, y G x'. 

The STT defines the four basic axioms for the variables and the types they can range over: Identity, 
Extensionality, Comprehension, and Infinity. We add the Intensionality on as the fifth axiom. The vari- 
ables in the definition of the Identity relationship and in the Extensionality and Comprehension axioms 
typically range over the elements of one of the two nearby types. In the set membership, only the un- 
primed variables that range over the lower type in the hierarchy can appear on the left of E; conversely, 
the primed ones that range over higher types can only appear on the right of G. The axioms are defined 
as: 

1 . Identity: x = y ^y^[x £ z' ^ y £ z'] 

2. Extensionality: Vx[x G 3^' ^ x G z'] —>-y' = z' 

3. Compreliension: 3z'Vx[jc G z' ^ This covers objects and arrays as any collection of ele- 
ments here may form an object of the next, higher type. The STT states the comprehension axiom 
is schematic with respect to ^{x) and the types. 

4. Infinity: \/x,y[x / j — > [x/?}' Vj^]]- There exists a non-empty binary relation R over the elements 
of the atomic type that is transitive, irreflexive, and strongly connected. 

5. Intensionality: the intensional types and operators are based on the intensional logic and context 
calculus. These are extensively described in the works ifTSl l20l l23l [T2]| and related. This present 
type system accommodates the two in a common hybrid execution environment of the GIPSY. A 
context c is a finite subset of the relation: c C {{d,x)\d G DIM Ax G T}, where DIM is the set of 
all possible dimensions, and T is the set of all possible tags. 

2.1 Types of Types 

Types of types are generally referred to as kinds. Kinds provide categorization to the types of similar 
nature. While some type systems provide kinds as first class entities available to programmers, in GIPSY 
we do not expose this functionality in our type system at this point. However, at the implementation level 
there are provisions to do so that we may later decide to expose for the use of programmers. Internally, 
we define several broad kinds of types, presented the the sections that follow. 
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2.1.1 Numeric Kind 

The primitive types under this category are numerical values, which are represented by GIPSYInteger, 
GIPSYFloat, and GIPSYDouble. They provide implementation of the common arithmetic operators, 
such as addition, multiplication and so on, as well as logical comparison operators of ordering and 
equaUty. Thus, for a numerical type T , the following common operators are provided. The resulting type 
of any arithmetic operator is the largest of the two operands in terms of length (the range of double of 
length say k covers the range of int with the length say m and if both appear as arguments to the operator, 
then the resulting value's type is that of without loss of information, i.e. largest in length double). The 
result of the logical comparison operators is always Boolean B regardless the length of the left-hand-side 
and right-hand-side numerical types. 



1. 


Tmax -Ti >T2 ^ T\ \ Ti < T2 T2 


2. 


Tmultiply ■ Tjc X T,„ > 7^ax(<:,Hi) 


3. 


Tdivide ■ Tk/T,n > 7max(/:,m) 


4. 


Tadd '-Tk-l-Tm > 7"max(<:,m) 


5. 


Tsuhtract ■ Tk T^ > ^^ax(/t,m) 


6. 


Tmod '■ Tk%Tfn > 7^nax(*:,m) 


7. 


Tpow - Tk T,n > 7max(/:,m) 


8. 


r> : r > r ^ B 


9. 


r< : r < r ^ B 


10. 


T>:T>T^B 


11. 


T<:T <T ^ B 


12. 


T= :T = T ^B 



A generalized implementation of the arithmetic operators is done by realization of the interface 
called lArithmeticOperatorsProvider and its concrete implementation developed in the general 
delegate class GenericArithmeticOperatorsDelegate. This design and implementation allow not 
only further exposure of kinds-as-first-class values later on after several iterations of refinement, but 
also will allow operator and type overloading or replacement of type handling implementation alto- 
gether if some researchers wish to do so. The implementation of the engine, GEE, is thus changed, 
to only refer to the interface type implementation when dealing with these operators. Equivalently for 
the logic comparison operators we have the ILogicComparisonOperatorsProvider class and the 
corresponding GenericLogicComparisonOperatorsDelegate class. The latter relies on the com- 
parator implemented for the numerical kind, such as NumericComparator. Using comparators (i.e. 
classes that implement the standard Comparator interface) allows Java to use and to optimize build- 
in sorting and searching algorithms for collections of user-defined types. In our case, the class called 
GenericLogicComparisonDperatorsDelegate is the implementation of the delegate class that also 
rehes on it. The example for the numeric types for the described design is in Figure [T] 

It is important to mention, that grouping of the numeric kind of integers and floating-point numbers 
does not violate the IEEE 754 standard [5J, as these kinds implementation-wise wrap the corresponding 
Java's types (which are also grouped under numeric kind) and their semantics including the implemen- 
tation of IEEE 754 by Java in accordance with the Java Language Specification. 
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GenericArithmeticOperatorsDelegate 

(from lang) 




NumericComparator 

(from comparators) 


^GenericArithmeticOperatorsDelegateO 
^addO 


> 


^NumericComparatorO 
^compareQ 

^getfvlARFSourceCodeRevisionO 








Figure 1 : Example of Provider Interfaces and Comparators 



2.1.2 Logic Kind 

Similarly to numeric types, the primitive type GIPSYBoolean fits the category of the types that can be 
used in the Boolean expressions. The operations the type provides expect the arguments to be of the 
same type - Boolean. The following set of operators on the logic type B we provide in the GIPSY type 
system: 



1- Band ■ B /\B B 

2. Bor:B\JB^B 

3. B„ot ■ ^B B 

4. B,or :B®B^B 

5. Bnand '■ ~^{B /\B) B 

6. Bnor : ^{By B) ^ B 



Note that the logical XOR operator (denoted as 0) is different from the corresponding bitwise op- 
erator in Section 2.1.3 similarly to as the bitwise vs. logical are for AND and OR. Again, simi- 
larly to the generalized implementation of arithmetic operators, logic operator providers implement the 
ILogicOperatorsProvider interface, with the most general implementation of it in the delegate class 
GenericLogicOperatorsDelegate. 



2.1.3 Bitwise Kind 

Bitwise kind of types covers all the types that can support bitwise operations on the the entire bit length 
of a particular type T. Types in this category include the numerical and logic kinds described earUer in 
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Section [2.1.2 and Section 2.1.1 The parameters on both sides of the operators and the resulting type are 
always the same. There are no implicit compatible type casts performed unlike for the numeric kind. 

1- Thit-and '■ T&T T 

2. Thit-ar -TlT > T 

3. Thit-not :\T 

4. Thu-,or:T^T 

5. Th,;-„and : \{T &.T) ^ T 

6. Thit-nor '■ 1{T\T) 

The generalized implementation of this kind's operators is done through the interface that we called 
IBitwiseOperatorsProvider, which is generically implemented in the corresponding delegate class 
GenericBitwiseDperatorsDelegate. 



2.1.4 Composite Kind 

As the name suggests, the composite kind types consist of compositions of other types, possibly ba- 
sic types. The examples of this kind are arrays, structs, and abstract data types and their realization 
such as objects and collections. In the studied type system these are GIPSYObject, GIPSYArray, and 
GIPSYEmbed. This kind is characterized by the constructors, dot operator to decide membership as well 
as to invoke member methods and define equality. The design of of these types, just like the entire 
type system, adheres to the Composite design pattern. The most prominent examples of this kind are in 
Figure[2j including GIPSYContext which is composed of Dimensions and indirectly of the TagSets. 



GIPSYType 

(romlang) 









GIPSVObjsct 

(from lang) 



.<1- 





GIPSYArray 

(from 1 ang) 


] — 






GIPSYIdentifier 

(fromldng) 



nsioriTags 
-oDimensionName 



GIPSYEmbed 

(from lang) 




GIPSYConteKt 

(from lang) 


> 


Dimension 

(from context) 

















Figure 2: Composite Types. 



2.1.5 Intensional Kind 

The intentional types kind primarily has to do with encapsulation dimensionality, context information and 
their operators. These are represented by the types GIPSYContext, Dimension, and TagSetQtypes. The 

'Not mentioned here; please refer to I19II15I . 
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common operators on these types include the context switching and querying operators @ and # as well 
as context calculus operators. Additional operators can be included depending on the intensional dialect 
used, but the mentioned operators are said to be the baseline operators that any intensional language 
can be translated to use. Implementation-wise there is a IContextSetOperatorsProvider interface 
and its general implementation in GenericContextSetOperatorsDelegate. The context calculus 
operators on simple contexts include standard set operators, such as union, difference, intersection, and 
Lucx-specific isSubContext, projection, hiding, and override Iil9.il5<l . 

2.1.6 Function Kind 

The function types represent either "functional" functions, imperative procedures, and binary and unary 
operators that, themselves, can be passed as parameters or returned as results. In our type system these 
are represented by GIPSYFunction, GIPSYDperator, and GIPSYEmbed. The common operators on this 
include equality and evaluation. 

3 Describing Some GIPSY Types' Properties 

To show the overview of the properties of GIPSY types to get a better and more complete understanding 
of the spectrum of their behavior we cover them in light of description and comparison to existential, 
union, intersection, and linear types. 

3.1 Existential Types 

All of the presented GIPSY types are existential types because they represent and encapsulate modules 
and abstract data types and separate their implementation from the public interface specified by the 
abstract GIPSYType. These are defined as follows: 

T = 3GIPSYType{0bject a; Object getEnclosedTypeObject(); Object getValue();} 
The above is implemented in the following manner, e.g.: 

boolT {Boolean a; Object getEiiclosedTypeObject(); Boolean getValue(); } 
intT {Long a; Object getEnclosedTypeObject(); Long getValue(); } 
doubleT {Double a; Object getEnclosedTypeObject(); Double getValue();} 
... and so on. 

All these correspond to be subtypes of the the more abstract and general existential type T . Assuming 
the value ? G T, then ?.getEnclosedTypeObj ect() and ?.getValue() are well typed regardless the what 
the GIPSYType may be. 

3.2 Union Types 

A union of two types produces another type with the valid range of values that is valid in either of 
the two; however, the operators defined on the union types must be those that are valid for both of the 
types to remain type-safe. A classical example of that is in C or C-i~i- the range for the signed char is 
— 128 . . . 127 and the range of the imsigned char is 0. . .255, thus: 

signed char U unsigned char = —128 . . .255 

In C and C-i~i- there is a union type that roughly corresponds to this notion, but it does not enforce the 
operations that are possible on the union type that must be possible in both left and right types of the 
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uniting operator. In the class hierarchy, such as in GIPSY, the union type among the type and its parent 
is the parent class; thus, in our specific type system the following holds: 

Vr G G : rUGIPSYType = GIPSYType 
GIPSYArrayUGIPSYObject = GIPSYObject 
GIPSYVoid U GIPSYBoolean = GIPSYBoolean 
GIPSYOperatorUGIPSYFunction = GIPSYFunction 

where T is any concrete GIPSY type and G is a collection of types in the GIPSY type system we are 
describing. Equivalently, the union of the two sibling types is their common parent class in the inheri- 
tance hierarchy. Interestingly enough, while we do not expUcitly expose kinds of types, we still are able 
to have the following union type relationships defined based on the kind of operators they provide as 
siblings under a common interface: 

Vr g A : r U lArithmeticOperatorProvider = lArithmeticOperatorProvider 

Vr £ L:TU ILogicDperatorProvider = ILogicOperatorProvider 

Vr G -B : r U IBitwiseDperatorProvider = IBitwiseOperatorProvider 

Vr g C : ru IContextDperatorProvider = IContextOperatorProvider 

vr S D : r U ICompositeDperatorProvider = ICompositeOperatorProvider 

vr Cz F : T (J IFunctionOperatorProvider = IFunctionOperatorProvider 

where T is any concrete GIPSY type and A is a collection of types that provide arithmetic operators, 
L - logic operators providers, B - bitwise operators providers, C - context operators providers, D - 
composite operator providers, and F - function operator providers. Thus: 

{GIPSYInteger, GIPSYFloat, GIPSYDouble} e A 
{GIPSYBoolean} G L 

{GIPSYInteger, GIPSYFloat, GIPSYDouble, GIPSYBoolean} G B 
{GIPSYContext, Dimension} G C 

{GIPSYObject, GIPSYArray,GIPSYEmbed},GIPSYString} G D 
{GIPSYFunction, GIPSYDperator,GIPSYEmbed} G F 

Another particularity of the GIPSY type system is the union of the string and integer types under dimen- 
sion: 

GIPSYInteger UGIPSYString = Dimension 

and this is because in our dimension tag values we allow them to be either integers or strings. While not 
a very common union in the majority of type system, they do share a common set of tag set operators 
defined in [|20,I for ordered finite tag sets (e.g. next (), etc.). 

3.3 Intersection Types 

Intersection type of given two types is a range where the sets of valid values overlap. Such types are 
safe to pass to methods and functions that expect either of the types as the intersection types are more 
restrictive and compatible in both original types. A classical example of an intersection type if it were 
implemented in C or C-i~i- would be: 

signed char n unsigned char = . . . 127 

The intersection types are also useful in describing the overloaded functions. Sometimes the are called 
as refinement types. In the class hierarchy, the intersection between the parent and child classes is the 
most derived type, and the intersection of the sibhng classes is empty. While the functionahty offered 
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by the intersection types is promising, it is not currently explicitly or implicitly considered in the GIPSY 
type system, but planned for the future work. 

3.4 Linear Types 

Linear (or "uniqueness") types are based on linear logic. The main idea of these types is that values 
assigned to them have one and only one reference to them throughout. These types are useful to describe 
immutable values like strings or hybrid intensional-imperative objects (see ll24ll for details). These are 
useful because most operations on such an object "destroys" it and creates a similar object with the 
new values, and, therefore, can be optimized in the implementation for the in-place mutation. Implicit 
examples of such types in the GIPSY type system are GIPSYString that internally relies on Java's 
StringBuffer that does something very similar as well as the immutable GIPSYObject is in JOOIP 
|[24l and immutable GIPSYFunction. Since we either copy or retain the values in the warehouse, and, 
therefore, one does not violate referential transparency or create side effects in, and at the same time be 
more efficient as there is no need to worry about synchronization overhead. 

4 Conclusion 

Through a series of discussions, specification, design, and implementation details we presented a type 
system used by the GIPSY for static and dynamic type checking and evaluation of intensional and hybrid 
intensional-imperative languages. We highlighted the particularities of the system that does not attribute 
to a particular specific language as traditionally most type systems do, but to an entire set of languages 
and hybrid paradigms that are linked through the type system. We pointed out some of the limitations 
of the type system and the projected work to remedy those limitations. Overall, this is a necessary 
contribution to GIPSY-like systems to have a homogeneous environment to statically and dynamically 
type-check intensional and hybrid programs. 

4.1 Future Work 

The type system described in this paper has been implemented in the GIPSY. However, due to recent 
changes including the introduction of contexts as first-class values in Generic Lucid, as well as the 
development of the fully-integrated hybrid language JOOIP |24|, our implementation still needs thorough 
testing using complex program examples testing the limits of the type system. Additional endeavours, 
noted in the previous sections of this paper, include: 

• Exposing more operators for composite types to Lucid code segments. 

• Allowing custom user-defined types and extension of the existing operators and operator overload- 
ing. 

• Expose kinds as first class entities, allowing programs more explicit manipulation of types. 

• Consider adding intersection types for more flexibility in the future development of the type sys- 
tem, allowing more type casting possibilities at the programming level. 
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